前言

在說到Service Mesh(服務網格)之前，前段時間最火紅的應該就是屬於MicroService(微服務)，因此我們今天來探討有關於MicroService跟Service Mesh差別在哪，以及在開發上有哪些觀念有許多的差異性。

MicroService

MicroService在討論的時候，有許許多多的人會把它跟Container(容器化)劃上等號，但實際上不必然。一個系統有嚴密的模組化，有將每個模組的Business Logic(商業邏輯)切割開來，用上Domain Driven Design(領域驅動設計)，廣泛來說這些模組都可以算是MicroService。

不過我們系列的重點是放在Service Mesh以及Kubernetes的使用，因此我們還是得討論使用Container技術的MicroService。

MicroService + Container

加上Container的MicroService，究竟有什麼魔力讓許許多多的工程師，前撲後繼的往這個方向探索，簡單來說利用Container的技術，我們可以做到服務的獨立且快速部署，服務運行時的環境一致性以及快速的擴充。但是當Container越來越多，越來越難以管理，還要負責維護許多Middleware，來保證整個MicroService可以長期穩定運行，例如Service Discovery、Service Monitor、Service Deployment...等等，所以後面出現了一個好用且很潮的管理工具Kubernetes。

Kubernetes

Kubernetes的出現，讓許多開發者眼睛為之一亮，這個工具提供了眾多的套件，以及管理Container的Life Cycle，如果對於Kubernetes有許多興趣的可以移駕去旁邊棚，那邊有許多大神級的人物。我這邊就不多贅述，直接往今天的主題Service Mesh前進。

Service Mesh(Istio)

有了Kubernetes為什麼我們還要使用Service Mesh的架構?在Kubernetes大多人都會使用NameSpace或者是Cluster去區隔環境或者是服務，甚至有許多混合雲以及External Service的多種應用，這樣對於只懂開發的工程師來說，非常痛苦，除了要懂開發程式，還要知道服務之間的各種連接？還要能正確地將服務接上?

以及如果要更改連線上的設定，還要從程式碼修改，雖然已經MicroService and Container，可以快速部署但還是需要花費非常高的成本去進行維護，所以我們採用Sidecar Pattern的概念，使用Istio提供的Envoy Proxy去做到Service To Service，減低對服務本身程式碼維護的衝擊。

結語

希望能透過這個系列，讓大家能夠更了解MicroService到Service Mesh的發展，後面會再詳細提到Kubernetes上Istio運作的模式。

圖片來源:
Pattern: Service Mesh
What is Kubernetes
Out of the Clouds onto the Ground: How to Make Kubernetes Production Grade Anywhere